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Abstract. These notes are a companion to [1] which describe 

— the variable conditions that Smallfoot checks, 

— the analysis used to check them, 

— the algorithm used to compute a set of verification conditions corre- 
sponding to an annotated program, and 

— the treatment of concurrent resource initialization code. 



2012 Introduction 

This document presents the variable conditions and checking algorithms as im- 
plemented in Smallfoot 0.1 of late 2005. These conditions on the proof rules for 
concurrency rely on some of the relaxations introduced by Brookes [3] relative 
to O'Hearn's system [7], and so originally soundness was via Brookes's result. 
Ian Wehrman and Berdine have since found some cases where these relaxed 
conditions are unsound, prompting a revisitation of this topic. Brookes [4] and 
Reddy and Reynolds [9] have recently introduced systems which address these 
issues while admitting encodings of proofs in O'Hearn's more restrictive system 
(among other improvements). 

In hindsight, while Smallfoot needs more than O'Hearn's system, it does 
not use the full relaxation of Brookes's original system, in particular retaining 
concurrency condition 5 below. As a result, the proofs found by Smallfoot appear 
to be embeddable into either of the recently proposed sound systems, although 
we do not claim to have a formal proof at this time. 

The condition checking algorithms remain non-compositional, and hence uses 
a whole-program analysis, despite the compositionality of both Brookes's revised 
system and that of Reddy and Reynolds. This is a result of the necessity of 
guiding the search for a proof to one which satisfies the occurrence conditions, 
as opposed to the distinct problem of checking whether a given candidate proof 
outline satisfies the conditions, or of inferring a valid permissions annotation as 
in [9]. 



1 Checking Variable Conditions 

1.1 Annotated Programs 

Each Smallfoot program determines a resource environment r which contains 
the resource declarations 

where x*i and Ri are resource rj's protected variables and invariant; and a pro- 
cedure environment A which contains the procedure declarations 

f(p;v)[P f ]C f [Q f ] 

where procedure f's parameters p are passed by reference and v by value, and 
assertions Pf and Qf are f's pre- and post-conditions. We assume that r and 
A are given. 

Commands are generated by: 

E ::= x | nil | c | ExorE 
B ::= E=E \ E^E 

S ::= x:=E \ x:=E^t \ E^t:=E | x:=new() | dispose(£') 
C ::= S 1 | C ; C \ U(B) {C} else {C*} | while(S) [7] {C} 
| f(x ; i?) | f(x ; E) || /(f ; E) \ with r when(B) {C} 

1.2 Legal Annotated Programs 

Using the following notation 

owned (r) = ^ 

i.Ti Gr 

var(r) = owned(r) U [J fv(Ri) 

i.riEr 

where r denotes a set of resources, the set of legal annotated programs is re- 
stricted by the following constraints: 

— In any procedure call f(y ; E) or region with r when(i?) {C} the variable f/r 
must be defined in a procedure/resource declaration. 

— In every procedure declaration f(p ; Cj [Qf], the formal parameters 
p, v are all distinct. 

— The resources r must be distinct. 

— The protection lists must all be disjoint: owned(ri) n owned(rj) = when 

— No resource's invariant may have a free occurrence of a variable in a distinct 
resource's protection list: fv(Ri) CiXj =0 when i ^ j. 
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1.3 Simplifying Assumptions 



Additionally, we assume a pre-processing phase which renames bound variables 
to satisfy the following simplifying assumptions: 

— Bound variables (formal parameters and variables bound by local) are dis- 
tinct from one another, and from global variables. 

— For each procedure declaration, variables in the postcondition are not bound 
(by local) in the body. 

1.4 Variable Conditions 

We define functions var(— ), mod(— ), req(— ) on commands C and procedure 
names /. Intuitively: 

— var(C) is set of variables that C mentions (in the program or specifications, 
recursively) without protection; 

— mod(C) is the set of variables that C may modify without protection (ac- 
quiring r protects owncd({r})); 

— rcq(C) is the set of resources required to be acquired before executing C. 

The auxiliary function er(M,A), returning the set of resources that need to be 
acquired before modifying variables in M and accessing variables in A, is defined 
as: 



The definition proceeds by performing a simple fixpoint calculation to determine 
the least solution (which is best) of the following equations, ordering by point- 
wise subset inclusion of functions: 



where f(p ; v)[P] C [Q] £ A, and for commands: 

var(x:=E) = {x} U fv(E) 
var(x:= E->t) = {x} U fv(E) 
var(E^t:=F) = fv(E) U fv(F) 
var(x:=new()) = {x} 
var (dispose (Ej) = fv(E) 

var{C ; C) = var(C) U var(C") 
var (if (B) {C} else {C}) = fv(B) U var(C) U var(C") 
var(while( J B) [/] {C}) = fV(7, B) U var(C) 




r 



r(x)R G r and 

(A n x ^ or M n (xUfv(R)) ^ 0) 



var(f) = (var(C) U fv(P, Q)) - (pU v) 
mod(f) = mod(C) - (pU v) 
rcq(f) = req(C) U er(0, fv(P, Q) - (pU v)) 
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var(f(x ; E) 
var(f(x;E) \\ f{x'-E') 
var(with r when(£>) {C} 



= var(f)UxUfv(E) 

= var(f(x;E))Uvar(f(x';E')) 

= ((fv(B) U var(C)) - fv(R r )) U (mod(C) - owned{{r})) 



mod(x:= E) 


= to 




mod(x:= E->t) 


= to 




mod(E^t:= F) 


= 




mod(x:=nev(j) 


= to 




mod(dispose(£?)) 


= 




modyu ; O J 


= mod(C) U mod(C) 




moOL(\±\t> ) |Oj- else |(_/ j- J 


= mod(C) U mod(C") 




mod (while (±>) |ij (Cjj 


= mod(C) 




mod(f(x;E)) 


= mod(f) U x 




mod(f(x;E) \\ f'(a7;E')) 


= mod(f(x;E))Umod(f'( 


f ; E')) 


mod(with r when(B) {C}) 


= mod{C) — owncd({r}) 




req(S) 


= er(mod(S),var(S)) 




rcq{C;C) 


= req(C) U req(C") 




req(±f(B) {C} else {C"» 


= req(C) U rcq(C) U er(0, fV(£)) 


req(while(B) [I] {C}) 


= req(C) U er(0, fV(i", B)) 




req(f(x ; E)) 


= req(f)Uer(x,fv(E)) 




req(f(x;E) \\ f(x';E')) 


= req(f(x;E))Ureq(f(x' 


&)) 


req(with r when(B) {C}) 


= (req(C) U er(0, fv(S))) - 


{r} 



The definitions of var and mod are as expected, except that CCR statements 
with r when(i?) {C} hide accesses and modifications of the variables owned(r) in 
C. Note that variables in fv(R r ) can only be modified in a critical region for r. 
Therefore, when computing the external effect of a command with r when(_B) {C} 
we can ignore the reads to fv(R r ) since they can never happen in parallel with 
a write. For req, any mention of a variable protected by r, or modification of a 
variable in r's invariant, causes r to be required; and a CCR for r discharges the 
requirement of r. 

Variable Aliasing Conditions The variable conditions for aliasing follow 
those of [6] and [5] . The conditions needed to avoid variable (not heap) aliasing 
are enforced by checking, for every procedure call f(x;E) in the program: 

- The actual reference parameters x are distinct. 

— If a global variable z is passed by reference, then / and procedures / calls, 
recursively, must not read or modify z, or mention it in specifications: x n 
var(f) = 0. 
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Variable Conditions for Concurrency The variable conditions for concur- 
rency follow those of [8,7,3]. The first two concurrency conditions: 

1. Protected variables of r appear only within OCRs for r. 

2. Variables appearing in a resource r's invariant can only be modified within 
CCRs for r. 

are checked using the computed req(-). A violation of one of these conditions 
results in "too large" a required resources set for the offending code, which 
eventually propogates to the main procedure. Hence, we check that req(main) = 
0, if it appears. Note that this analysis ignores deadlock due to acquiring an 
already-held resource, as Smallfoot only proves safety. 
The third and fourth concurrency conditions: 

3. Only protected variables can be modified in one parallel process and read or 
mentioned in specifications in another. 

4. For each parallel composition f(x ; E) \\ f'(x' ; £/), f(x ; E) and the specifi- 
cation of / cannot mention variables modified by f'(x' ;E'), and vice versa. 

are checked using the computed var(— ) and mod{— ): 

mod(f(x ; E)) n (fv(P' , Q') U var(/'(f ; E'))) = 
and mod(f'(x' ; E')) n (fv(P, Q) U var(f(x ; E))) = 0, 
where f(p ; v) [P] C [Q] , f(jf ; if) [P'} C [Q'\ G A. 

The final concurrency condition is a property of program proofs, not of an- 
notated programs themselves: 

5. Whenever a CCR is symbolically executed, the pre and post states cannot 
mention variables modified by other processes. 

Note that according to the inference rule for CCRs, entering a CCR adds the 
resource invariant to the current precondition. Also, it may be that processes 
running in parallel with the one executing the CCR under consideration modify 
variables appearing in the added invariant. For this reason, we introduce a further 
analysis which computes, for each procedure /, the set par(f) of procedures that 
might run in parallel with /: 

1. par(f) D {/'} for all occurrences of f(x;E) || f(x';E') or f(x';E') |j f(x;E) 
in the program; 

2. par(f') D par(f) for all occurrences of f'(x" ; E 1 ) or f'(x' ; E') \\ f"(x" ; E") 
or f"(x";E") \\f(x>;E>) mC f . 

(As before, we take the smallest set satisfying the above conditions.) The results 
of this analysis are then used in VCGen to instrument the VCs for CCRs so that 
any such variables modified by processes in parallel are quantified out of the 
post states of CCRs during symbolic execution, thereby avoiding bad proofs. 

Checking the concurrency conditions essentially classifies each variable into 
one of the following five classes: 
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Local variables are declared by local, or are procedure value parameters. Their 
use is unrestricted within their scope. 

Process-local variables appear, and are mentioned in specifications, in only 
one process, and do not appear in any resource invariants. In that process, 
their use is unrestricted. 

Global-constant variables appear in some function and are not local. They 
cannot be written to but can be read or appear in specifications, including 
resource invariants, in any process. 

Protected variables are those which appear in one resource's protection list, 
and can be modified, accessed, or mentioned in specifications in any process, 
but only within critical regions for the associated resource. 

Process-protected variables appear in at least one resource invariant and in 
only one process. In that process they are modified only within critical re- 
gions for all the resources in whose invariants they appear. Also in that pro- 
cess, they can be read and appear in specifications outside of critical regions. 
Variables which appear free in some resource invariant but are not protected 
are either process- protected or global-constant, depending on whether they 
are ever written to. 



2 Verification Condition Generation 

2.1 Verification Conditions 

A verification condition is a triple [P] SI [Q] where SI is a "symbolic instruction" : 

SI ::=e\S | [P] jsr s [Q] | if B then SI else SI \ SI; SI 

A symbolic instruction is a piece of loop- free sequential code where all procedure 
calls have been instantiated to jsr instructions of the form [P] jsr s [Q]. This form 
plays a central role in Smallfoot. We use it not only to handle procedure calls, 
but also for concurrency and for entry to and exit from a critical region. 

Scmantically, [P]]sr s [Q] is a "generic command" in the sense of [10]. It is 
the greatest relation satisfying the pre- and post-condition, and subject to the 
constraint that only the variables in x are modified. 

The symbolic execution rule for the jsr instruction is: 

77 A S h 77' A S' * S F [(n[x /x]) A Q * (E F [x'/x})} C [R] 
[77AZ]([77'AZ']jsr s [Q];C) [R] 

To apply this rule we have to discover a frame axiom Sp which describes the 
portion of heap unchanged by a procedure call, and [2] describes a proof-theoretic 
method for obtaining them. 

2.2 VCGen 

For each procedure declaration f(p ; v)[P] C [Q] we generate a set of verification 
conditions vcg(f, [P] C[Q]), which is itself defined using a helper function chop 
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that takes a command and produces a symbolic instruction together with a set 
of verification conditions, vcg just runs chop on the body C, tacks the pre and 
post onto the resulting symbolic instruction, and adds that to the verification 
conditions returned by chop. 



vcg(g,{P}C{Q}) = {[P}SI[Q}}UL 

where SI , L = chop(g, C) 

chop(g, S) = S,9 
chop(g, C;C') = SI; SI' , L' U L' 

where SI , L = chop(g, C) and Si' , V = chop(g, C) 
chop(g, if(B) {C} else {C}) = if B then SI else SI' , L U L' 

where SI , L = chop(g, C) and SI' , L' = chop(g, C') 
chop(g,»hile(B) [I] {C}) = [i] jsr mod(c) [->B A /] , vcg([B M]C [I]) 

chop(g,f(x ; E)) = ([emp]jsr [if=E A emp] ;[P[x/p, & /v\] }sr mod{Cf )[x/p,v> /v\ [Q[x/p, v' /v]]) , 
where f(p ; v)[P] C [Q] and v 1 fresh 
cho P (g,f(x;E) || /'(f ; E')) = ([emp] jsr [v=E A if=E' A emp] ;[P * P'] jsr^, [Q*Q']),0 

where [emp] jsr [w=£? A emp] ;[P] jsr ? [Q] , = chop(g, f(x ; i?)) 
[emp]jsr A emp] ;[P']jsr ? , [Q'] , = chop(g,f'(x" ; £')) 

chop(g, with r when(i?) {C}) = ([true A emp] jsr [BAR]; SI ; [true A R}]sr SuS [true A emp]) , L 

where SI , L = chop(g, C) and r(x)R and u = fv(-R) n U/e pa r(g) m °d(f) 

The definition of chop for primitive statements, sequential composition, con- 
ditionals and loops is mostly as expected, except that for loops we generate a jsr 
instruction that allows invariants to be smaller than they might otherwise be, 
because of framing. 

For procedure call, we rename the value parameters and use two jsr's: the 
first to initialize the renamed parameters and the second to abstract the body 
of the procedure, using only its spec. This renaming allows the postcondition 
to refer to the initial value of the parameters which are not modified by the 
body. The composition of the two jsr's satisfies a spec [A] — [B] iff the second 
one satisfies [^4 A v'—E] — [B]. In the definition, mod(Cf) is the set of variables 
modified by Cf (or one of the procedures that Cj calls) except for protected 
variables modified within a CCR. 

For parallel composition we emit two jsr's that combine the initializations of 
the two procedure calls, and take the ^-combinations of the respective precon- 
ditions and postconditions, following the parallel proof rule 

[P]C[Q] [P']C'[Q'} 
[P * P'] C || C [Q * Q'] . 

Entry to, and exit from, OCRs is modeled by jsr instructions. The entry jsr 
adds the resource invariant and boolean condition to the symbolic state. Since 
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this represents adding any concrete heap satisfying the invariant and condition, 
upon entry to a CCR the body cannot assume or depend on anything further 
about the acquired heap. This is how we handle potential interference from 
parallel processes, which may change one concrete heap satisfying the invariant 
to another. Additionally, outside interference is prevented in code following a 
CCR since the exit jsr removes the resource invariant from the symbolic state 
and forgets the values of variables which are protected, x, or might be modified 
by processes par(/) running in parallel, u. The net result is that correctness of 
a parallel program is reduced to several sequential triples, and no interleaving 
needs to be considered. This vc definition follows the description of the CCR 
proof rule 

[(P * Rr) A B] C [Q * Rr] 
[P] with r when(S) {C} [Q] 

(where R r is an invariant formula associated with resource r) and both occur- 
rences of jsr make use of the frame axiom inference capability; the precondition 
P of a CCR is maintained after the entry jsr, and an appropriate Q part for the 
postcondition in the rule is discovered as a frame axiom for the exit jsr. The 
r(x)R in the where clause indicates that R is the declared invariant of r in the 
program. 

To tie all of this together there is one further check that must be made. The 
init procedure must establish all of the resource invariants, separately, and the 
precondition of main if a main procedure is included. So given init()[P] C [Q] 
and main()[P'] C [Q'\ we check the entailment Q h R\ * ■ ■ ■ * R n * P'. We also 
require C to not contain procedure calls, CCRs, or parallel compositions. All told, 
the property that this establishes (following the rule for complete programs [7, 
3]) for a program is 

[P] C ; RESDECLS ; let PROCDECLS in C [Q' * fli * • • • * R n ] 

where PROCDECLS consists of those procedure declarations other than main 
and init. (We could also include a finalization procedure that disposes of the Ri 
at the end.) 

3 Resource Initialization 

Resource initializers are subject to the following constraints: 

1. No resource's initializer modifies a variable mentioned by a distinct resource: 
mod(C\) n var(rj) = when i ^ j. 

This is performed by checking, for all i 

mod(Ci) n var(Ci, . . . , CVi) = 
and var(Ci) n mod(Ci, . . . , CVi) = 

2. The init procedure, if it appears, and the resource initializers Ci contain no 
procedure calls or CCRs. 



8 



These constraints ensure that the order in which the initializers are executed 
is immaterial. Therefore, we have an additional verification condition: 



vcg([P]C[Q*R 1 *---*R n }) 



where R 



R n are all the resource invariants and 



P,C,Q 



( 




if init()[P'] C [Q'\ e A 



where C\, . . . , C n are all the resource initializers (in some unspecified order). 

Also, in case init appears, the precondition of procedure main, if it appears, 
is taken to be the postcondition of init, irrespective of what appears in the file. 
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